![]() |
Java Database Programming with JDBC
by Pratik Patel Coriolis, The Coriolis Group ISBN: 1576100561 Pub Date: 10/01/96 |
Previous | Table of Contents | Next |
One of JavaSofts first tasks in developing the JDBC API was to get it into the hands of developers. Defining the API specification was a major step, but JDBC drivers must be implemented in order to actually access data. Because ODBC has already established itself as an industry standard, what better way to make JDBC usable by a large community of developers than to provide a JDBC driver that uses ODBC. JavaSoft turned to Intersolv to provide resources to develop a bridge between the two, and the resulting JDBC driverthe Bridgeis now included with the Java Developers kit.
The Bridge works great, but there are some things you need to understand before you can implement it properly. In this chapter, well cover the requirements necessary to use the Bridge, the limitations of the Bridge, and the most elegant way to make a connection to a JDBC URL. Ill also provide you with a list of each JDBC method and the corresponding ODBC call (broken down by the type of call).
One thing to note about the JDBC-ODBC Bridge is that it contains a very thin layer of native code. This librarys sole purpose is to accept an ODBC call from Java, execute that call, and return any results back to the driver. There is no other magic happening within this library; all processing, including memory management, is contained within the Java side of the Bridge. Unfortunately, this means that there is a library containing C code that must be ported to each of the operating systems that the Bridge will execute on. This is obviously not an ideal situation, and invalidates one of Javas major advantagesportability. So, instead of being able to download Java class files and execute on the fly, you must first install and configure additional software in order to use the Bridge. Heres a short checklist of required components:
Before actually attempting to use the Bridge, save yourself lots of headachesbe sure to test the ODBC drivers that you will be using! I have pursued countless reported problems that ended up being nothing more than an ODBC configuration issue. Make sure you setup your data sources properly, and then test them to make sure you can connect and perform work. You can accomplish this by either using an existing tool or writing your own sample ODBC application. Most vendors include sample source code to create an ODBC application, and Microsoft provides a tool named Gator (a.k.a ODBCTE32.EXE) which can fully exercise ODBC data sources on Win95/NT.
All looks good for the Bridge; it gives you access to any ODBC data source, and its free! But wait, there are a few limitations that I need to make you aware of before you start.
First, as I mentioned before, a lot of software must be installed and configured on each system that will be using the Bridge. In todays environment, this feat cannot be accomplished automatically. Unfortunately, this task can be a major limitation, not only from the standpoint of getting the software installed and configured properly, but ODBC drivers may not be readily available (or may be quite costly) for the operating system that you are using.
Second, understand the limitations of the ODBC driver that you will be using. If the ODBC driver cant do it, neither can the Bridge. The Bridge is not going to add any value to the ODBC driver that you are using other than allowing you to use it via JDBC. One of the most frequently asked questions I get is: If I use the Bridge, can I access my data over the Internet? If the ODBC driver that you are using can, then the Bridge can; if it cant, then neither can the Bridge.
Third, keep in mind the quality of the ODBC driver. In order for the Bridge to properly use an ODBC driver, it must be ODBC version 2.0 or higher. Also, if there are bugs in the ODBC driver, they will surely be present when you use it from JDBC.
Finally, there are Java security considerations. From the JDBC API specification, all JDBC drivers must follow the standard security model, most importantly:
For trusted applets and any type of application, the Bridge can be used in any fashion to connect to any data source. For untrusted applets, the prognosis is bleak. Untrusted applets can only access databases on the server from which they were downloaded. Normally, the Java Security Manager will prohibit a TCP connection from being made to an unauthorized hostname; that is, if the TCP connection is being made from within the Java Virtual Machine (JVM). In the case of the Bridge, this connection would be made from within the ODBC driver, outside the control of the JVM. If the Bridge could determine the hostname that it will be connected to, a call to the Java Security Manager could easily check to ensure that a connection is allowed. Unfortunately, it is not always possible to determine the hostname for a given ODBC data source name. For this reason, the Bridge always assumes the worst. An untrusted applet is not allowed to access any ODBC data source. What this means is that if you cant convince the Internet browser in use that an applet is trusted, you cant use the Bridge from that applet.
To make a connection to a JDBC driver, you must supply a URL. The general structure of the JDBC URL is
jdbc:<subprotocol>:<subname>
where subprotocol is the kind of database connectivity being requested, and subname provides additional information for the subprotocol. For the Bridge, the specific URL structure is:
jdbc:odbc:<ODBC datasource name>[;attribute-name=attribute-value]...
Previous | Table of Contents | Next |